An IEEE 802.1BR-based network topology (referred to herein as an extended bridge) is a logical network entity that comprises two different types of units: controlling bridge (CB) units and port extender (PE) units. The CB (of which there may be one or multiple) serves as the controller of the extended bridge and is responsible for performing control plane functions (e.g., Layer 2 switching, Layer 3 routing, etc.) with respect to network traffic passing through the bridge. In contrast the PEs, which connect to the CB and to other devices/hosts external to the extended bridge, act as non-intelligent devices and thus typically do not perform any local switching or routing; instead, their primary function is to provide additional data port terminations for the CB (thereby extending the port capacity of the CB). For example, each PE may be a switch/router with X number of physical data ports, which appear as virtual data ports on the CB. Upon receiving a data packet from an external device/host on an ingress data port, the PE forwards the data packet to the CB, which processes the data packet in hardware or software to determine an appropriate egress port through which the packet should be sent out. The CB then forwards the data packet to the PE housing the egress port for transmission through that port towards the next hop destination.
PEs are generally connected to the CB according to a tree or chain topology, with the CB being the root of the tree/chain. The leaf-level PE nodes in the topology are known as edge PEs and the PE nodes at intermediate connection (e.g., tree branch) points are known as transit PEs. The edge PEs provide network services to various end hosts, which may include physical machines and/or virtual machines (VMs). In some embodiments, for scaling purposes, an extended bridge may include multiple CBs that connect to each other to form a linear or ring-based core stack. In these cases, the extended bridge may include multiple PE trees/chains, each rooted under a separate CB; such a configuration is sometimes referred to as a PE forest. One CB in the core stack may be designated as the master CB of the extended bridge and act as the central point of management for the entire bridge. Other CB s in the core stack may operate in a standby or member mode.
In recent years, there has been significant interest in deploying extended bridges for various high traffic volume applications such as campus networks, virtualized data centers (VDCs), private clouds, and the like. To support these and other similar use cases, an extended bridge should be highly scalable in multiple dimensions—e.g., in terms of number of connected PEs, number of network services supported, types of security threats that can be detected/neutralized, etc. However, one limiting factor to such scalability is the capacities of the hardware rule tables (i.e., ternary content addressable memories, or TCAMs) that reside on the CB(s). These TCAMs are typically programmed with packet classification rules that enable the CB(s) to make line-rate forwarding decisions with respect to the traffic passing through the bridge. When an extended bridge is scaled in various dimensions, the number of packet classification rules that need to be programmed into the TCAMs of the CB(s) will generally increase proportionally; in very large-scale systems, this number may grow into the millions or more. However, due to their cost and power requirements, the capacity of CB-level TCAMs are limited to a few hundred thousand rules at most. Thus, the TCAM capacities of the CB(s) in an extended bridge can become a critical bottleneck for system scalability.